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We describe the LHCb detector simulation application (Gauss) based on the Geant4 toolkit. The application 
is built using the Gaudi software framework, which is used for all event-processing applications in the LHCb 
experiment. The existence of an underlying framework allows several common basic services such as persis- 
tency, interactivity, as well as detector geometry description or particle data to be shared between simulation, 
reconstruction and analysis applications. The main benefits of such common services are coherence between 
different event-processing stages as well as reduced development effort. The interfacing to Geant4 toolkit is 
realized through a fagade (GiGa) which minimizes the coupling to the simulation engine and provides a set of 
abstract interfaces for configuration and event-by-event communication. The Gauss application is composed of 
three main blocks, i.e. event generation, detector response simulation and digitization which reflect the different 
stages performed during the simulation job. We describe the overall design as well as the details of GAUSS 
application with a special emphasis on the configuration and control of the underlying simulation engine. We 
also briefly mention the validation strategy and the planing for the LHCb experiment simulation. 



1. Introduction 

The LHCb pj experiment is one of the four main 
experiments that will be performed using the Large 
Hadron Collider (LHC), presently under construction 
at the European Organization for Nuclear Research 
(CERN) in Geneva, Switzerland. The experiment is 
devoted to the precision measurements of CP violation 
in the B meson system. 

The simulation applications are of major impor- 
tance both for the studies during the construction 
phase as well as during the running of the detector. 
The assumption is that they produce data ("digits") 
that would normally be available from the electronics 
of the detector. This simulated data is then fed, in the 
same way as the real data would be, into the recon- 
struction and further on into the analysis applications. 
The LHCb collaboration is moving to a complete chain 
of object-oriented event processing software. With the 
new reconstruction and analysis applications already 
used in production, the simulation one is getting close 
to that stage as well. 

The new object-oriented LHCb detector simula- 
tion application (Gauss) is based on the Geant4 
toolkit and is currently entering its final phase of 
development. It is built within the LHCb software 
framework (Gaudi) Q which is also used by the rest 
of the LHCb event-processing software. The existence 
of the common underlying framework allows sharing 
of many basic services such as persistency, interac- 
tivity, histograming, etc. In addition, it provides a 
natural way of having common sources of data such 
as the detector geometry, the magnetic field map, 
or the particle properties. The actual interfacing of 



Geant4 toolkit to the Gaudi framework is done by 
GiGa (Gaudi Interface to Geant4 Application) 0. 

The organization of this paper is the following. We 
will start with a brief presentation of the general struc- 
ture of the Gaudi framework followed by a description 
of the structure of GAUSS application itself. After 
that, we will discuss a few selected aspects of GiGa 
which are particularly relevant as the functional de- 
sign of Gauss is concerned. Finally we will briefly 
present a few results of our physics validation and we 
will formulate some conclusions. 

2. Overview of the underlying software 
framework 

The philosophy of the Gaudi framework is that each 
application consists of a set of "algorithms" which 
represent some self-contained functional parts of the 
programme. Those algorithms behave like pluggable 
components. They can be easily added, removed, ex- 
ecuted in series or separately. The job configuration, 
i.e. specification of the sequence of algorithms to be 
executed, setting of their options, defining input and 
output files, etc, is done via job options files, which 
are simply text files, read at the beginning of each job 
execution. 

On the other hand, the existence of the so-called 
transient data stores which are used for the commu- 
nication between the algorithms, guarantees the lack 
of mutual dependence between them. For instance, 
if an algorithm uses as an input MCHits to produce 
MCDigits, the only thing it requires is that there are 
some MCHits available in the transient store. It does 
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not care whether those MCHits come from a simula- 
tion algorithm which was executed beforehead or from 
a data file which was used to populate the transient 
store. Moreover, if at the moment when the algo- 
rithm requested the MCHits from the transient store 
they were not there yet, it will be the framework who 
will take care of reading the appropriate file (if avail- 
able of course) in order to populate the store. From 
the point of view of the algorithm, it will be a com- 
pletely transparent procedure, and in particular the 
implementation of the algorithm will not depend in 
any way on the persistent technology used. 

Such an architecture allows a modular structure 
of the whole simulation programme, introducing less 
coupling between different stages of the simulation 
job. The existence of the transient stores, provides 
also natural "communication channels" with other 
sets of algorithms such as the reconstruction algo- 
rithms or the visualization algorithms. In some sense, 
an "application" becomes a less well-defined entity, 
since one is able to combine any collection of algo- 
rithms into one executable sequence. One can imag- 
ine, for instance, running the simulation algorithms 
together with the visualization ones, providing a dis- 
play of each simulated event. It is useful to stress 
here once again, that those different algorithms can be 
developed completely independently without imple- 
menting any specific interfaces between them (apart 
from the ones defined by the framework to communi- 
cate with the transient stores). 



3. Overview of the simulation application 

The GAUSS simulation application consists of three 
major blocks responsible for the event generation, de- 
tector response simulation and digitization (see Fig- 
ure ^) . These three blocks are completely indepen- 
dent and, using the features of the underlying frame- 
work described in the previous section, can be exe- 
cuted separately reading (saving) the data from (to) 
the persistent stores. The format used to store the 
generated event (the output from the MC generators) 
is the HepMC event record @. As far as the sim- 
ulated event (the output from the detector simula- 
tion) is concerned, Gauss uses the LHCb event for- 
mat [||, which is then used as the input format for 
the reconstruction applications. As mentioned before, 
due to the existence of the underlying software frame- 
work, providing in particular the persistency service, 
the simulation application is fully independent from 
the underlying persistent technology. At the present 
moment, for instance, we are using the ROOT [9j file 
format to save the information on the disk, but this 
could be changed at any time, without affecting the 
actual simulation application. 

We will now go a little bit more into details and 
describe the first two blocks from Figure fj3 i- e - the 
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Figure 1: Structure of the GAUSS simulation application 
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Figure 2: Event generation sequence 



event generation and the interfacing to the simulation 
toolkit. The third block, being the digitization, is very 
detector-specific and therefore we will not discuss it 
here. 



3.1. Event generation 

The main event generator for Gauss is Pythia 
0- It is used to produce both the minimum-bias as 
well as the signal events. The actual decays of the 
b-hadrons are performed, however, using a dedicated 
decay package called EvtGen 0- Both Pythia, as 
well as EvtGen are wrapped inside special Gaudi 
algorithms (called PythiaAlg and EvtDecayAlg, re- 
spectively) which make them to behave like pluggable 
components (callable and controllable) in the Gaudi 
framework. The configuration of those MC genera- 
tors can, therefore, be done via the Gaudi job options 
interface. 

As mentioned before, the generated events are 
stored in the HepMC event record, which also serves 
to communicate between different generators (decay 
packages). The entire sequence of the event genera- 
tion is shown on Figure [3 First Pythia is called to 
generate the primary event. The settings of Pythia 
are such that most of the physical particles (those 
known to Geant4) are declared stable, and there- 
fore the generated event consists, at this stage, of 
one physical vertex (store in the transient store in the 
HepMC format). Such an approach seems to be nat- 
ural from the point of view of the detector response 
simulation which is performed afterwards. The excep- 
tion, however, are the decays of the b-hadrons. Those 
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are the most important in our simulation, and we want 
to have full control over them in order to be able to 
explicitly generate particular decay channels. In or- 
der to do so, the selection algorithm (SetDecayAlg) 
is called, which marks particles (normally b-hadrons) 
that should be decayed by the specialized package (the 
others will be left to be decayed by Geant4). Once 
that selection is performed, the EvtDecayAlg is exe- 
cuted. It calls EvtGen for each particle marked be- 
forehead and adds the decay products to the HepMC 
tree. Geant4 will later on use that information in 
the context of the forced decay channel mechanism. 

The final step in the event generation sequence is 
to call an additional algorithm which simulates the 
smearing of the position of the primary vertex (due 
to the size of the colliding beams). It generates the 
spread in the x, y and z directions according to dis- 
tributions specific for the LHC beams, which are then 
used to shift the position of all the vertices in the 
event. 

Such an architecture is very flexible and can be eas- 
ily extended. It is very easy to add other (replace) 
event generators, without any change to the code of 
the remaining simulation chain. Having more than 
one event generator implemented (wrapped) in the 
form of the Gaudi algorithm, one can run different 
configurations (replacing, for example Pythia with 
some other primary generator) without any recompi- 
lation but simply with different job options. 

3.2. Interface to the simulation toolkit 

The detailed description of the technical aspects of 
the Gaudi Interface to Geant4 Application (GiGa) 
can be found in Q and therefore we will not repeat it 
here. We will rather concentrate on a few selected as- 
pects of GiGa which are particularly interesting from 
the point of view of the overall simulation application. 

As mentioned before, one of the advantages of build- 
ing the simulation application on top of the common 
software framework is that it allows us to use sources 
of detector data, i.e. geometry description, magnetic 
field map, etc, shared with other applications such 
as the reconstruction or the visualization. The con- 
version of the LHCb geometry model to the Geant4 
geometry tree is done at the beginning of each simula- 
tion job by a specialized geometry conversion service. 
It is worth noting that the actual geometry configura- 
tion can be also changed via the job options, without 
any need for recompilation. The specification of "sen- 
sitive volumes" is done via simple declarations of the 
corresponding sensitive detectors class names in the 
persistent description of the shared geometry data (for 
which we use the XML format). One can add, remove 
or change sensitive detectors by simply editing the ge- 
ometry description file. Those changes are then taken 
into account at the runtime and the instantiation of 




Figure 3: Interface between Geant4 and Gaudi 
environment 



the required sensitive detectors is done using the ab- 
stract factory approach. The overall structure of the 
way Geant4 is interfaced to the Gaudi environment 
is shown in Figure 

As we can see there, the actual Geant4 engine is 
put behind a facade pattern which provides a uni- 
fied high level abstract interface. A set of abstract 
interfaces implemented within GiGa allows loading 
from the Gaudi transient stores into Geant4, de- 
tector geometry, primary event data, etc. It also 
makes it possible to use standard Gaudi services 
such as Magnetic Field service or Job Options ser- 
vice to be used by the Geant4 application. Let 
us mention as well that GiGa, through the exis- 
tence of a specialized class called GiGaRunManager, 
provides internal access to the Geant4 event loop. 
The standard G4RunManager : : BeamOn method is 
never used in the context of GiGa. The con- 
struction of the primary events is done via direct 
calls to G4Event : : AddPrimaryVertex method and 
the simulation is triggered by direct calls to the 
G4EventManager : : ProcessOneEvent method. This 
gives us more control over the each simulation run 
and provides us an extra flexibility as far as the con- 
struction of the primary events is concerned. 

Probably the most interesting feature of GiGa as 
the interface to the underlying framework is that all 
the "actions" such as event action, tracking action, 
etc, are instantiated using the abstract factory ap- 
proach and therefore can be loaded at the runtime. 
Such a design insures a very flexible structure of the 
simulation program and allows running different con- 
figuration by changing only the job options. As far as 
the physics lists are concerned, they are implemented 
in the form of Geant4 modular physics list and also 
are instantiated via the abstract factories. This again 
makes the architecture flexible, facilitating validation 
of different physics lists without a need of recompila- 
tion. 

Let us illustrate the interplay between the under- 
lying framework and the Geant4 toolkit on the con- 
crete example of the sensitive detectors and hit cre- 
ation. Figure 0| shows the whole chain starting from 
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Figure 4: Sensitive detectors and hits in Gauss 



the sensitive volume declaration and ending with the 
creation of the LHCb event model hits. 

Once Geant4 is aware of the given sensitive de- 
tector (instantiated using an abstract factory, as de- 
scribed at the beginning of this section), it will fol- 
low the standard procedure of calling the ProcessHit 
method every time there is a particle passing by the 
volume associate to it. The possible result of that 
(if the required conditions are satisfied, like the non- 
zero charge of the passing particle, etc.) will be the 
creation of Geant4 hits, stored in the Geant4 hit 
collections. The last part of the chain will be the 
conversion of all the created Geant4 hits during the 
given event, into the LHCb event model hits stored af- 
terwards in the Gaudi transient data store (and avail- 
able for the other algorithms like digitization, or for 
the serialization) . Such a conversion is performed by a 
specialized GiGa converted at the end of each event. 

From this example we can see that the user doesn't 
actually deal directly with the "Geant4 world". He 
declares the sensitive volumes in the "Gaudi world" 
and he gets the final output (simulated hits and par- 
ticles) back in the Gaudi transient store. 
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Figure 5: Number of simulated VELO hits per event 
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Figure 6: Energy deposition in the VELO Silicon sensors 

4. Physics validation 



The physics validation of the new LHCb simula- 
tion program is done in two ways: by comparing 
with the test beam data and by comparing with the 
Geant3 simulation results. The former approach is 
used to validate particular processes like the Rayleigh 
scattering or the Cherenkov radiation in the material 
of the Ring Imaging Cherenkov counters (RICH), or 
hadronic interaction models for the calorimeter. The 
later approach is used more to test the overall simula- 
tion chain, together with the event generation phase. 
What we will briefly present in this section is a few 
comparison plots between the Geant3 and Geant4 
results for the tracker-like devices in the LHCb. 

4.1. Vertex Locator physics validation 

The Vertex Locator (VELO) is the LHCb subde- 
tector inside which the interaction point is placed. It 



consists of a series of Silicon sensors and its purpose 
is to perform precise measurements of tracks close to 
the interaction region. Those measurements are es- 
sential for the reconstruction of production and decay 
vertices of the beauty- and charm-hadrons. 

We have examined several different histograms 
(multiplicities, distributions in space, energy deposi- 
tions, time of flight, etc) produced using simulated 
data and they all show a good agreement between 
the Geant3 and Geant4 based applications. In the 
Figures and El we see for instance the multiplicity 
of simulated VELO hits and the energy deposition in 
the Silicon of sensors. 

In some cases, like for example for the time of flight 
distribution shown on Figured we see that Geant4 
plot looks actually "smoother" for the lower values, 
which is probably due to the higher precision com- 
pared to Geant3. 
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Figure 7: Time of flight distribution for particles creating 
hits in the VELO Silicon sensors 



Figure 9: Time of flight distribution for particles creating 
hits in the Outer Tracker 
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Figure 8: Momentum distribution for particles creating 
hits in the Outer Tracker 

4.2. Outer Tracker physics validation 

The outer tracking detector in LHCb consist of drift 
cells with straw-tube geometry. In the configuration 
of the tracking stations the emphasis is on tracking 
precision in the (x,z) magnet bending plane. 

In order to validate the new simulation program, we 
have again compared a number of different distribu- 
tions. In most of the cases, as we can see for instance 
for the momentum distribution of particles creating 
hits shown in Figure |S1 we have not observed any sig- 
nificant discrepancies between the events simulated by 
Geant4 and Geant3. The only clearly visible differ- 
ence was in the time of flight distribution, which we 
can see in Figure 

It seems that in the Geant3 simulation there are 
more particles with longer time of flights (and less 
with shorter ones, since the overall multiplicity seems 



to be the same) than in the Geant4 simulation. This 
result is not yet understood and we are currently in- 
vestigating any possible cause of that difference. 



5. Status and conclusions 

Over the last year the Geant4 based simulation ap- 
plication for the LHCb experiment has evolved from 
a set individual components to a fully functional pro- 
gram. Its major parts such as the interfaces to Monte- 
Carlo generators, the interface to the Geant4 toolkit, 
as well as different sensitive detectors are, to a large 
extend, implemented. Due to the underlying software 
framework, many of the components, such as the de- 
tector description, are shared between the simulation 
as well as the other applications like the reconstruction 
or the visualization. The interface between Geant4 
and that framework extensively uses the concept of 
abstract factories which makes the simulation envi- 
ronment very flexible and easily configurable. 

The LHCb is now testing its new simulation appli- 
cation. With most of the results being positive, the 
move to the Geant4 based simulation is being pre- 
pared. The LHCb is planing to start extensive test 
productions in the summer 2003 and to move defi- 
nitely to the GEANT/4-based simulation application at 
the beginning of the year 2004. 
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